Encode modules with variable-length integers#2322
Merged
Merged
Conversation
Update `Module::{serialize,deserialize}` to use variable-length integers
with `bincode` to make the output artifacts smaller. Locally this
reduces the size of bytecodealliance#2318 from 160 to 110 MB, a 30% decrease in size!
Deserialization performance is slightly slower, but seemingly within the
range of noise locally for me.
github-actions
Bot
added
the
wasmtime:api
Subscribe to Label Actioncc @peterhuene DetailsThis issue or pull request has been labeled: "wasmtime:api"Thus the following users have been cc'd because of the following labels:
To subscribe or unsubscribe from this label, edit the |
yurydelendik
approved these changes
Oct 26, 2020
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this pull request
Oct 26, 2020
This commit reduces the size of `InstructionAddressMap` from 24 bytes to 8 bytes by dropping the `code_len` field and reducing `code_offset` to `u32` instead of `usize`. The intention is to primarily make the in-memory version take up less space, and the hunch is that the `code_len` is largely not necessary since most entries in this map are always adjacent to one another. The `code_len` field is now implied by the `code_offset` field of the next entry in the map. This isn't as big of an improvement to serialized module size as bytecodealliance#2321 or bytecodealliance#2322, primarily because of the switch to variable-length encoding. Despite this though it shaves about 10MB off the encoded size of the module from bytecodealliance#2318
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this pull request
Oct 27, 2020
This commit reduces the size of `InstructionAddressMap` from 24 bytes to 8 bytes by dropping the `code_len` field and reducing `code_offset` to `u32` instead of `usize`. The intention is to primarily make the in-memory version take up less space, and the hunch is that the `code_len` is largely not necessary since most entries in this map are always adjacent to one another. The `code_len` field is now implied by the `code_offset` field of the next entry in the map. This isn't as big of an improvement to serialized module size as bytecodealliance#2321 or bytecodealliance#2322, primarily because of the switch to variable-length encoding. Despite this though it shaves about 10MB off the encoded size of the module from bytecodealliance#2318
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this pull request
Nov 3, 2020
This commit reduces the size of `InstructionAddressMap` from 24 bytes to 8 bytes by dropping the `code_len` field and reducing `code_offset` to `u32` instead of `usize`. The intention is to primarily make the in-memory version take up less space, and the hunch is that the `code_len` is largely not necessary since most entries in this map are always adjacent to one another. The `code_len` field is now implied by the `code_offset` field of the next entry in the map. This isn't as big of an improvement to serialized module size as bytecodealliance#2321 or bytecodealliance#2322, primarily because of the switch to variable-length encoding. Despite this though it shaves about 10MB off the encoded size of the module from bytecodealliance#2318
alexcrichton
added a commit
that referenced
this pull request
Nov 3, 2020
This commit reduces the size of `InstructionAddressMap` from 24 bytes to 8 bytes by dropping the `code_len` field and reducing `code_offset` to `u32` instead of `usize`. The intention is to primarily make the in-memory version take up less space, and the hunch is that the `code_len` is largely not necessary since most entries in this map are always adjacent to one another. The `code_len` field is now implied by the `code_offset` field of the next entry in the map. This isn't as big of an improvement to serialized module size as #2321 or #2322, primarily because of the switch to variable-length encoding. Despite this though it shaves about 10MB off the encoded size of the module from #2318
Member
|
To be clear this is just enabling variable length encoding for integers, right? It is not switching to a delta encoding (which would ensure that essentially all addresses are 1-byte encoded) correct? |
Member
Author
|
Ah yes indeed, a delta encoding might make it even more further compact. I've so far shied away from big changes like that though. I think we may want to do it eventually, but it trades-off in-memory footprint for lookup speed since we can no longer quickly do a random lookup for a particular trapping pc. Not that we necessarily need that to be too too fast. |
Member
|
I'm only advocating for delta encoding in the serialized format, not the in-memory representation. |
Member
I think it'd be good to try not to have those two deviate too much: ideally we should at some point be able to mmap the on-disk representation entirely or almost entirely instead of having to read and deserialize it. There clearly are size/speed tradeoffs to be had here, so that might not be the only thing we support, but I hope it can become a thing we support :) |
cfallin
pushed a commit
that referenced
this pull request
Nov 30, 2020
Update `Module::{serialize,deserialize}` to use variable-length integers
with `bincode` to make the output artifacts smaller. Locally this
reduces the size of #2318 from 160 to 110 MB, a 30% decrease in size!
Deserialization performance is slightly slower, but seemingly within the
range of noise locally for me.
cfallin
pushed a commit
that referenced
this pull request
Nov 30, 2020
This commit reduces the size of `InstructionAddressMap` from 24 bytes to 8 bytes by dropping the `code_len` field and reducing `code_offset` to `u32` instead of `usize`. The intention is to primarily make the in-memory version take up less space, and the hunch is that the `code_len` is largely not necessary since most entries in this map are always adjacent to one another. The `code_len` field is now implied by the `code_offset` field of the next entry in the map. This isn't as big of an improvement to serialized module size as #2321 or #2322, primarily because of the switch to variable-length encoding. Despite this though it shaves about 10MB off the encoded size of the module from #2318
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Update
Module::{serialize,deserialize}to use variable-length integerswith
bincodeto make the output artifacts smaller. Locally thisreduces the size of #2318 from 160 to 110 MB, a 30% decrease in size!
Deserialization performance is slightly slower, but seemingly within the
range of noise locally for me.